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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document is part of a series of documents that specify charging functionality and charging management in 
GSM/UMTS networks. The GSM/UMTS core network charging architecture and principles are specified in 3GPP 
TS 32.240 [1], which provides an umbrella for other charging management TSs that specify: 

- the content of the CDRs per domain and subsystem (offline charging), 

- the content of real-time charging messages per domain / subsystem (online charging); 

- the functionality of onhne and offline charging for those domains and subsystems; 

- the interfaces that are used in the charging framework to transfer the charging information (i.e. CDRs or charging 
events) 

The complete document structure for these TSs is defined in TS 32.240 [1]. 

The present document specifies the Offline and Online Charging for MultiMedia Telephony (MMTel) service and 
supplementary services, based on the functional description of MMTel in 3GPP TS 22.173 [200]. Charging for the 
following supplementary services is specified: 

Communications Diversion (CDIV) 

Communication Hold (HOLD) 

- CONFerence (CONF) 

Message Waiting Indication (MWI) 

Originating Identity Presentation (OIP) / Originating Identity Restriction (OIR) 

Terminating Identity Presentation (TIP) / Terminating Identity Restriction (TIR) 

- Call Barring (CB) 

- Explicit Call Transfer (ECT) 
Communication Wait (CW) 

Editor" s Note: Specification of other MMTel supplementary services is PES. 

Charging of these supplementary services is performed at the respective MMTel AS. The MMTel charging aspects are 
an extension of the basic IMS charging capabilities as specified in the TS 32.260 [20]. 

This charging description includes the offline and online charging architecture and scenarios specific to the MMTel, as 
well as the mapping of the common 3GPP charging architecture specified in TS 32.240 [1] onto the MMTel. It further 
specifies the structure and content of the CDRs for offline charging, and the charging events for onhne charging. 

The present document is related to other 3GPP charging TSs as follows: 

The common 3GPP charging architecture is specified in TS 32.240 [1]; 

The common IMS charging principles are specified in the TS 32.260 [20]. 

The parameters, abstract syntax and encoding rules for these CDR types are specified in TS 32.298 [51]. 

A transaction based mechanism for the transfer of CDRs within the network is specified in TS 32.295 [54]. 

The file based mechanism used to transfer the CDRs from the network to the operator"s billing domain (e.g. 
the billing system or a mediation device) is specified in TS 32.297 [52]. 

The 3GPP Diameter application that is used for MMTel offline and online charging is specified in 
TS 32.299 [50]. 
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All references, abbreviations, definitions, descriptions, principles and requirements, used in the present document, that 
are common across 3GPP TSs, are defined in the 3GPP Vocabulary, TR 21.905 [100]. Those that are common across 
charging management in GSM/UMTS domains or subsystems are provided in the umbrella document TS 32.240 [1]. 
Finally, those items that are specific to the present document are defined exclusively in the present document. 



2 References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 



• 



References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[1] 3GPP TS 32.240: "Telecommunication management; charging management; charging architecture 

and principles". 

[2]-[19] Void 

[20] 3GPP TS 32.260: "Telecommunication management; Charging management; IP Multimedia 

Subsystem (IMS) charging". 

[21]-[49] Void. 

[50] 3GPP TS 32.299: "Telecommunication management; Charging management; Diameter charging 

application". 

[51] 3GPP TS 32.298: "Telecommunication management; Charging management; Charging Data 

Record (CDR) parameter description". 

[52] 3GPP TS 32.297: "Telecommunication management; Charging management; Charging Data 

Record (CDR) file format and transfer". 

[53] 3GPP TS 32.296: "Telecommunication management; Charging management; Online Charging 

System (OCS) applications and interfaces". 

[54] 3GPP TS 32.295: "Telecommunication management; Charging management; Charging Data 

Record (CDR) transfer". 

[55]-[99] Void. 

[100] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 

[101] 3GPP TS 22.101: "Service aspects; Service Principles". 

[102] 3GPP TS 22.1 15: "Service aspects; Charging and bilHng". 

[103] 3GPP TS 23.002: "Network Architecture". 

[104]-[199] Void. 

[200] 3GPP TS 22.173: " Multimedia Telephony Service and supplementary services;stage 1". 

[201] 3GPP TS 24.173: "IMS multimedia telephony communications service and supplementary 

services stage3". 

[202] 3GPP TS 24.604: "TISPAN- PSTN/ISDN simulation services: Communication Diversion (CDIV); 

Protocol specification". 
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[203] 3GPP TS 24.605: . "Conference (CONF) using IP Multimedia (IM) Core Network (CN) 

subsystem; Protocol specification". 

[204] 3GPP TS 24.606: "Message Waiting Indication (MWI) using IP Multimedia (IM) Core Network 

(CN) subsystem; Protocol specification". . 

[205] 3GPP TS 24.607: "Originating Identification Presentation (OIP) and Originating Identification 

Restriction (OIR) using IP Multimedia (IM) Core Network (CN) subsystem; Protocol 
specification". 

[206] 3GPP TS 24.608: "Terminating Identification Presentation (TIP) and Terminating Identification 

Restriction (TIR)using IP Multimedia (IM) Core Network (CN) subsystem; Protocol 
specification". 

[207] 3GPP TS 24.610: "Communication HOLD (HOLD) using IP Multimedia (IM) Core Network 

(CN) subsystem; Protocol specification". 

[208] 3GPP TS 24.61 1: "Anonymous Communication Rejection (ACR) and Communication Barring 

(CB)using IP Multimedia (IM) Core Network (CN) subsystem; Protocol specification". 

[209] 3GPP TS 24.615: "Communication Waiting (CW) using IP Multimedia (IM) Core Network (CN) 

subsystem; Protocol Specfication". 

[210] 3GPP TS 24.616: "Malicious Communication Identification (MCID) using IP Multimedia (IM) 

Core Network (CN) subsystem; Protocol specification". 

[211] 3GPP TS 24.623: "Extensible Markup Language (XML) Configuration Access Protocol (XCAP) 

over the Ut interface for Manipulating Simulation Services". 

[212] 3GPP TS 24.629: "Explicit Communication Transfer (ECT) using IP Multimedia (IM)Core 

Network (CN) subsystem;; Protocol specification". 

[213] 3GPP TS 24.642: "Completion of Communications to Busy Subscriber (CCBS) and Completion of 

Communications by No Reply (CCNR) using IP Multimedia (IM)Core Network (CN) subsystem; 
Protocol Specification". 

[214] 3GPP TS 24.647: "Advice Of Charge (AOC) using IP Multimedia (IM)Core Network (CN) 

subsystem; Protocol Specification". 

[215] 3GPP TS 24.654: "Closed User Group (CUG) using IP Multimedia (IM) Core Network (CN) 

subsystem, Protocol Specification". 

[216]-[299] Void. 

[300]- [399] Void. 

[400] Void. 

[401] IETF RFC 3588: "diameter base protocol". 

[402] IETF RFC 4006: "Diameter Credit Control Application". 

[403]-[499] Void. 



3 Definitions and abbreviations 

For the purposes of the present document, the following terms and definitions given in 3GPP TR 21.905 [100], 3GPP 
TS 32.240 [1]. 

3.2 Abbreviations 

For the purposes of the present document, the abbreviations defined in 3GPP TR 21.905 [100], 3GPP TS 32.240 [1] and 
the following apply: 
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MMTel MultiMedia Telephony 

CB Communication session Barring 

CCBS Completion of Communication sessions to Busy Subscriber 

CCNR Completion of Communications on No Reply 

CD Communication Deflection 

CDIV Communication Diversion 

CDIVN CDIV Notification 

CFB Communication Forwarding Busy 

CPU Communication Forwarding Unconditional 

CFNL Communication Forwarding on Not Logged-in 

CFNR Communication Forwarding No Reply 

CFNRc Communication Forwarding on Subscriber Not Reachable 

CFUDB Communication Forwarding User Determined Busy 

CONF CONFerence 

CW Communication Waiting 

ECT Explicit Communication Transfer 

HOLD Communication HOLD 

ICB Incoming Communication Barring 

MWI Message Waiting Indication 

OCB Outgoing Communication Barring 

OIP Originating Identity Presentation 

OIR Originating Identity Restriction 

TIP Terminating Identity Presentation 

TIR Terminating Identity Restriction 



Architecture Considerations 



4.1 High level IVIIVITel architecture 

Figure 4.1 depicts the IMS reference architecture, as described in 3GPP TS 23.002 [103], with "colorized " AS as entity 
involved in MMTel service and supplementary services charging described in this specification. 
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Figure 4.1-1 : Entities involved in MMTel service charging in IMS logical architecture 

The AS provides the appUcation level network functionality for MMTel service and supplementary services, whereas 
the overall IMS Network provides the basic IMS capabilities supporting MMTel service. 

4.2 MMTel offline charging architecture 

Figure 4.2 depicts the MMTel offline charging architecture. 
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Figure 4.2-1 : MMTel Offline Charging architecture 

This MMtel Offline Charging architecture is based on the IMS offline charging architecture described in TS 
32.260 [20], with service CTFs supporting MMtel specific service charging, interfacing the CDF through the Rf 
reference point. 

The CTFs considered in the MMTel Offline Charging architecture reside in the Application level network functionality 
providing MMTel service and supplementary services. 

The CTFs related to charging for the IMS basic capabilities supporting MMTel service, are described in TS 32.260 [20], 
and reside in the set of IMS Nodes (S-CSCF, MRFC.) reflected in IMS offline architecture. 



4.3 MMTel online charging architecture 

The architecture for MMTel online charging is described in the following figure. 
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Figure 4.3-1 : MMTel Online Charging architecture 

This MMtel Online Charging architecture is based on the IMS onHne charging architecture described in TS 32.260 [20], 
with service CTFs supporting MMtel specific service charging, interfacing the OCS through the Ro reference point. 

The CTFs considered in the MMTel Online Charging architecture reside in the Application level network functionality 
providing MMTel service and supplementary services. 

The CTFs related to charging for the IMS basic capabilities supporting MMTel service, are described in TS 32.260 [20], 
and reside in the set of IMS Nodes (S-CSCF, MRFC.) reflected in IMS online architecture. 



5 MMTel charging principles and scenarios 

There are a variety of multimedia telephony supplementary services implemented at different IMS nodes. All the 
services should support subscription based charging, and some also consumption based charging. The subscription 
based charging is out of the scope of the present specifications. 

The following table 5.1 summarizes which of the services are applicable for offline and online charging. 



ETSI 



3GPP TS 32.275 version 8.2.0 Release 8 



13 



ETSI TS 132 275 V8.2.0 (2009-10) 



Table 5.1 : Relevance of the services for offline and online charging 



Supplementary services 


Offline Charging 


Online Charging 


OIP 


X 


- 


OIR 


X 


- 


TIP 


X 


- 


TIR 


X 


- 


CW 


X 


- 


HOLD 


X 


- 


CB 


X 


- 


MWI 


X 


- 


CONF 


X 


X 


CDIV 


X 


X 


CDIVN 


X 


X 


ECT 


X 


X 



5.1 MMTel charging principles 



The MMTel charging encompasses the Multimedia telephony service (e.g. multimedia conversational communications 
between two or more users, with speech as a typical usage, and also others combinations of media) together with the 
associated supplementary services charging aspects. 

Every Supplementary services described in TS 22.173 [202] are subject to be involved in MMTel charging function 
description. 

Editor" s note: 

The whole IMS supplementary services list from 22.173 [202] is considered, although some of them could have no 
implication on charging: this need to be investigated and to be captured. 

MMTel service and supplementary services charging function focuses on charging information provided by the CTFs 
supporting MMtel specific service charging: calling user identification, called user identification, media component 
characteristics and usage (speech only, speech with other component, add/retrieve components..), supplementary 
services applied . . .It enables to apply different flexible charging based on supplementary service type and options. 

All the CTFs supporting MMtel specific service charging (AS) pertain to IMS domain, and as explained in TS 32.260 
[20], it is possible to correlate session/transaction related charging data generated from these different Nodes (AS), and 
others IMS Nodes involved in the session used for MMTel service handling , based on IMS Charging Identifier (ICID). 

5.1 .1 Supplementary services invocation 

Editor" s note: 

This chapter will specify for each supplementary service, if the invocation need to trigger charging, and which 
possible relevant information need to be provided during the service execution for charging. 

5.1.1.1 OIP charging 

The OIP service provides the terminating user with the possibility of receiving trusted (i.e. network-provided) identity 
information in order to identify the originating user. 

The charging of the OIP subscribers is measured by the MMTel AS handling OIP in offline charging only. 

5.1.1.2 OIR charging 

The OIR service is a service offered to the originating user. It restricts presentation of the originating user's identity 
information to the terminating user. 

The charging of the OIR subscribers is measured by the MMTel AS handling OIR in offline charging only. 
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5.1.1.3 TIP charging 

The Terminating Identification Presentation (TIP) service provides the originating party with the possibility of receiving 
trusted information in order to identify the terminating party. 

The charging of the TIP subscribers is measured by the MMTel AS handling TIP in offline charging only. 

5.1.1.4 TIR charging 

The Terminating Identification Restriction (TIR) is a service offered to the terminating party which enables the 
terminating party to prevent presentation of the terminating identity information to originating party. 

The charging of the TIP subscribers is measured by the MMTel AS handling TIR in offline charging only. 



5.1.1.5 HOLD charging 



The Communication Hold supplementary service enables a user to suspend the media stream(s) of an established IP 
multimedia session, and resume the media stream(s) at a later time. 

The charged parties may be any of the Hold parties. These roles are: 

• Calling Paity; 

• Called Party; 



Editor"s note: When one of the parties originates a new call to a third party and the new call overbooks the bearer 
resource reserved by the held call, overbooking may be taken into account in charging. The solution for 
that is ffs 

5.1.1.6 CB charging 

The Communication Barring (CB) service offers the following services: 

• The Incoming Communications Barring (ICB) is a service that rejects incoming communications that fulfil 
certain provisioned or configured conditions on behalf of the terminating user. 

• The Anonymous Communication Rejection (ACR) is a particular case of the ICB service, that allows barring 
of incoming communications from an anonymous originator on behalf of the terminating user. 

• The Outgoing Communication Barring (OCB) is a service that rejects outgoing communications that fulfil 
certain provisioned or configured conditions on behalf of the originating user. 

The charging of the CB subscribers is measured by the MMTel AS handling CB in offline charging only. 



5.1.1.7 CDIV charging 



The Communications Diversion (CDIV) services enables the diverting user, to divert the communications addressed to 
the diverting user to another destination. 

There are three actors active in a CDIV service of one diversion with the following roles: 

• Diverting user; the party that initiates the diversion of an incoming communication. 

• Originating user; the party which has initiated the communication and that stays in the communication which is 
diverted; 

• Diverted to user; 

In case there is another diversion, the user that was first the diverting user (user B), will be the originating user in the 
second diversion. The diverted to user of the first diversion (user C) will be the diverting user of the second diversion. 
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The charging of the diverting user for the B-C leg is measured by the MMTel AS handling the CDIV service, i.e. by the 
MMTel AS of the diverting user (user B). For the diverting user a separate charging dialog (online and/or offline 
charging) is needed. Charging of the originating and the terminating user (user C) is done in alignment with the TS 
32.260 [20]. 

Typically the diverting user is charged for the forwarded leg (B-C leg), however, normal roaming charging principles 
apply for the diverted to user also in case of communication diversion. If there is another diversion, the user that 
performs the second diversion (user C) is charged (typically) for the new forwarded leg (C-D leg). 

Charging at the S-CSCF is done in alignment with the TS 32.260 [20] but the S-CSCF has no knowledge of the CDIV 

service. 

5.1.1.8 CW charging 

The CW (Communication Waiting) service enables the application server to indicate to the subscriber, that there is at 
least one new communication is requested, and that no resources are available for that incoming communication. The 
user has then the choice of accepting, rejecting or ignoring the incoming communication. The maximum number of 
communications that may be waiting is a service provider option. If the current number of communications waiting is 
equal to the maximum, then any new attempted incoming communication request shall be rejected with a busy cause. 

The charging of the CW subscribers is measured by the MMTel AS handling CW in offline charging only. 

5.1.1.9 ECT charging 

The Explicit Communication Transfer (ECT) service provides a party involved in a communication to transfer that 
communication to a third party. 

There are three actors active in a transfer, they are acting in the following roles: 

• transferor: the party that initiates the transfer of the active communication that it has with the transferee; 

• transferee: the party which stays in the communication which is transferred; 

• transfer target: the party which the communication is transferred to and which replaces the transferor in the 
communication. 

The charging of the Transferor is measured by the MMTel AS handling the ECT service for the Transferor. The 
charging of the Transferee is measured by the MMTel AS handling the ECT service for the Transferee. 

5.1.1.10 MWI charging 

The MWI service enables the application server to indicate to the subscriber, that there is at least one message waiting. 
The indication is delivered to the subscriber's UE after successful subscription to the Message Waiting Indication 
service as described in the present document. 

The charging of the MWI subscribers is measured by the MMTel AS handling MWI in offline charging only. 



5.1.1.11 CONF charging 



The CONFerence (CONF) service enables a user to participate in and control a simultaneous communication involving 
a number of users. 

CONF Charging for the conference owner could be based on: 

• establishment of the conference 

• number of participants 

• duration 

CONF Charging for the conference participants could be based on: 
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• duration 

The charging of the conference owners and participants is measured by the SIP AS and MRFC handling conference 
service. For each participant (call leg) a separate charging dialog (online and/or offline charging) at the SIP AS is 
needed. 



5.1 .2 Supplementary services management by User 

When an IMS supplementary service control can be provided to the UE as a subscription option, every action performed 
by the user for this service (Provision/Withdrawal, Registration/Erasure, Activation/Deactivation, interrogation) may be 
subject to produce charging information, but this aspect is out of the scope of the present specification. 

5.2 MMTel offline charging scenarios 



5.2.1 Basic principles 



The MMTel offline charging functionality is based on the CTFs reporting accounting information, by sending Diameter 
Accounting Requests (ACR) [Start, Interim, Stop and Event] to the CDF. 

The circumstances on which the Diameter client uses ACR Start, Interim and Stop, or Events depend on the 
supplementary service type and is determined for each of them. Further details are specified in clause 5.2.2. 

These Diameter Accounting Request triggers may be configured in such a way several MMTel supplementary services 
can be regrouped. Providing this flexibility will allow to improve situations where several MMTel supplementary 
services are handled within the same AS for complying with interactions requirements associated to these MMTel 
supplementary services. 



5.2.2 Diameter message flows 

The flows described in the present document specify the charging communications between the different CTF entities 
and the charging functions for different charging scenarios. The SIP messages and Diameter transactions associated 
with these charging scenarios are shown primarily for general information and to illustrate the charging triggers. They 
are not intended to be exhaustive of all the SIP message flows discussed in TS 24.228 [200] and they depend on the 
Diameter Accounting Requests triggers configured by the operator. 

Although each MMTel supplementary service is described by separated flows illustrating the dedicated trigger(s) for 
this MMTel supplementary service, the Diameter Accounting Request triggers (as stated in 5.2.1), may be configured 
with several MMtel supplementary services information. 

5.2.2.1 Message Flows - Successful Cases and Scenarios 

Following message flows are defined in TS 32.260 [20], and can be re-used for charging the basic multimedia 
telephony capabilities: 

• Session Establishment - IMS Origination 

• Session Establishment - IMS Termination 

• Mid-Session Procedures 

• Session Release - Mobile Irutiated 

5.2.2.1.1 OIP Originating Identification Presentation 
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Figure 5.2.2.1.1-1 shows the Diameter transactions that are required between Application Server and CDF, which 
implements the OIP service, and CDF after service execution. 



Originating UE-A Home Network 



UE-A 



S-CSCF A 



1. INVITE 



3. 200 OK 



6. ACK 



1. INVITE 



3. 200 OK 



6. ACK 



Terminating UE-B Home Network 



S-CSCF B 



AS-B 



1. INVITE 



CDF 



UE-B is Subscribed to OIP 



2. INVITE 



3. 200 OK 



3. 200 OK 



6. ACK 



6. ACK 



2. INVITE 



3. 200 OK 



4. ACR [Start/Evt nt] 



UE-B 



UE-A is 
calling 



Open/Create an AS CDR 
Indicate OIP on the AS 
CDR 



5. ACA 



6. ACK 



Figure 5.2.2.1.1-1 : Message Sequence Chart for Offline charging of OIP service. 



5.2.2.1.2 



Originating Identification Restriction (OIR) 



Figure 5.2.2.1.2-1 shows the Diameter transactions that are required between Application Server and CDF, which 
implements the OIR service, and CDF after service execution. 
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Originating UE-A Home Network 



Terminating UE-B Home Network 



UE-A 



S-CSCF 



AS 



CDF 



x-CSCF/AS 



1. INVITE 



IPC for A 



^VITE (Privacy: 



3. 200 OK 



6. ACK 



l.INVITlE (Privacy: ID) 



If UE-A is 
Subscribed to OIR 

"Privacy: ID" info is 
added if not existing 
already 



ID) 



3. 200 OK 



3. 200 OK 



6. ACK 



6. ACK 



2. INVITE 



4. ACR [Start/Event] 



Privacy: ID) 



3. 200 OK 



Open/Create an AS CDR 
Indicate OIR on the AS 
CDR 



5. ACA 



6. ACK 



UE-B 



2. INVfTE (Privacy: Ip) 

► 



"Presentity 
withheld" 



3. 200 OK 



6. ACK 



5.2.2.1.3 



Figure 5.2.2.1.2-1 : Message Sequence Chart for Offline charging of OIR service. 



Terminating Identification Presentation (TIP) 



Figure 5.2.2.1.3-1 shows the Diameter transactions that are required between Application Server and CDF, which 
implements the TIP service, and CDF after service execution. 
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Originating UE-A Home Network 



Terminating UE-B Home Network 




AS 



CDF 



Session Initiation 



1.2000s; (Privacy: none) 



j . 200 OK (Privac 



4. ACK 



1.200 OK (Privac: : none) 



UE-A is subscribed to 
the TIP service. 



none) 



4. ACK 



4. ACK 



2. ACR [Start/Event] 

► 




1.200 OK (Privacy: none) 



Open/Create an AS CDR 
Indicate TIP on the AS 
CDR 



3. ACA 



4. ACK 



OK (Privacy: lone) 



4. ACK 



Figure 5.2.2.1.3-1 : Message Sequence Chart for Offline charging of TIP service. 



5.2.2.1.4 Terminating Identification Restriction (TIR) 

Figtire 5.2.2.1.4-1 shows the Diameter transactions that are required between Application Server and CDF, which 
implements the TIR service, and CDF after service execution. 
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Originating UE-A Home Network 



Terminating UE-B Home Network 



UE-A 



X-CSCF/AS 




1. 200 OK rPrivacIv 

< 



"Connected witli 
unknown" 



4. ACK 



x-CSCF B 



AS-B 



CDF 



Session initiation 



1.2 
1.200OKfPrivacv:ID) 



ID) 



4. ACK 



1. 200 OK 



1.200 OK tPrivacv: 



Privacv: ID) 



ID) 



UE-B is subscribed to 
the TIR service and 
can add the Privacy: 
ID header and value if 
they are missing. 



)0 OK (Privacv: ID) 

-* 



4. ACK 



4. ACK 



2. ACR [Start/Event] 

► 



UE-B 




Open/Create an AS CDR 
Indicate TIR service on AS 
CDR 



3. ACA 



4. ACK 



Figure 5.2.2.1.4-1 : Message Sequence Chart for Offline charging of TIR service. 



5.2.2.1.5 



Communication Hold (HOLD) 



Figure 5.2.2.1.5-1 shows the Diameter transactions that are required between AS which implements the HOLD service, 
and CDF after service execution. The involvement of the AS is optional as it is involved to the HOLD service provision 
only for announcement purposes. 
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Originating UE-A Home Network 



Terminating UE-B Home Network 



UE-A 



S-CSCF 



AS 



CDF 




Ongoing Session 



UE-A initiates 
session on hold 



1. UPDATE 
sip:[5555::5:6 
SIP/2.0... (SDFI ) 



2.200 OK 



5. ACK 



:1006;comp=sig 
a=sendonly / a= 



comp 
nactive 



1. UPDATE... 
< ► 



2.200 OK 



2.200 OK 



5. ACK 
< ► 



3. ACR [Start/I iterim/E vent] 




1. UPDATE. 



2.200 OK 



Open/Update/Create the AS CDR 
Indicate HOLD on the AS CDR 



4. ACA 



5. ACK 



1 .UPDATE. I 



"HOLD" 



2.200 OK 



5. ACK 



Figure 5.2.2.1.5-1 : Message Sequence Chart for Offline charging of HOLD service. 

Note: Based on TS 24.610 a scenarion triggerted by Re-Invite is also possible. 

5.2.2.1 .6 Communication Barring - CB (ICB/ACB) 

5.2.2.1 .6.1 Communication Barring (CB) - ICB and ACR 



Figure 5.2.2.1.6.1-1 shows the Diameter transactions that are required between Application Server and CDF, which 
implements the CB service, and CDF after service execution. 
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Originating UE-A Home Network 



Terminating UE-B Home Network 



UE-A 



X-CSCF/AS 



x-CSCF B 



AS-B 



CDF 



UE-B 



1. INVITE 



4.603 



(Decline) / 433 ( Anonymity Disallowed) 



1. INVITE 



4. 603 (Decline) / 433 



4. 603 (Decline) / 4|33 ( Anonymity Disallowed) 

•^ 



1. INVITE 



UE-B has matching 
ICB/ACR activated 



( Anonymity Disallo\j'ed) 

< 



2. ACR [Event] 



Create an AS CDR 
Indicate ICB/ACR on the 
AS CDR 



3. ACA 



Figure 5.2.2.1.6.1-1 : Message Sequence Chart for Offline charging of CB service. 



5.2.2.1.6.2 



Communication Barring (CB) - OCB 



Figure 5.2.2.1.6.2-1 shows the Diameter transactions that are required between Application Server and CDF, which 
implements the CB service, and CDF after service execution. 
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Originating UE-A Home Network 



UE-A 



X-CSCF 



AS 



CDF 



UE-B 



1. INVITE 
















4 
4. 603 (Decline) 


1. INVITE 


















UE-A has 
matching OCB 

nrtivatpfl 










2. ACR [Event] 




603 (Decline) 










Create an AS CDR 
Indicate OCB on the AS 
CDR 




3. AC 


:a 



















Figure 5.2.2.1.6.2-1 : Message Sequence Chart for Offline charging of CB service. 



5.2.2.1.7 



Communications Diversion (CDIV) 



5.2.2.1.7.1 



Communications Diversion (CDIV) - successful establishment 



The following figure shows the Diameter transactions that are required between Application Server,implementing the 
CDIV service and CDF for a successful communication forwarding on no reply. 
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Home Network 



S-CSCF 



1. INVITE 



AS 



iFC for User B 



2. 180 Ringing 



I. INVITE 



1. INVITE 



2. 180 Ringing 



2. 180 Ringing 



CDF 



1 . INVITE 



2. 180 Ringing 



3. Start Timer 



5. Cancel 



4. Timer Expired 



5. Cancel 



6 . SIP signalling :, CFNR logic, release call to user B and Invite towards user C 



8.200 OK 



7. INVITE (user C) 



8.200 OK 



8.200 OK 



7. INVITE (user C) 



8.200 OK 



9. Accounting Request [Start/E\ 



Open/Create an AS 



10. Accounting Answer 



More SIP signalling 



Figure 5.2.2.1.7.1-1 : Message Sequence Chart for Offline charging of CDIV service - establishment 



A communication is requested towards User B, user B has activated the CFNR 

1) INVITE request incoming for User B. Based on the Initial Filter Criteria (IFC) Rules, indicating that User B is 
subscribed to the CDIV supplementary services, the communication is forwarded to an AS implementing AS 
implementing CDIV. Then INVITE is forwarded to User B, 
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2) 180 ringing is sent back from User B. 

3) The non-reply timer in the AS is started . 

4) The timer expires. 

5 to 7) The AS implementing the CDIV service performs the Call Forwarding No Reply logic : release the 
communication to User B, and forward the call towards user C (INVITE request including URI-C as 
destination). 

Depending on the value of subscription option 'Originating user receives notification that his communication has 
been diverted (forwarded or deflected)', a 181 (Call Is Being Forwarded) response is sent towards the User A 
indicating that the communication is diverted (not shown in the call flow). 

8) The destination User C party answers and a final response is received. 

9) Upon reception of the final response, the AS implementing the CDIV service sends an Accounting-Request with 
Accounting-Record-Type indicating START_RECORD/EVENT_R£CORD to record call forwarding execution 
(start of the forwarded leg from User B to User C): basic communication information are transferred with 
specific call forwarding information ( service mode= 'CFNR', associated number = ' user B' as the user who 
invoked the call forwarding). 

10) The CDF acknowledges the reception of the data and opens/creates an AS CDR to record the forwarded leg from 
User B to User C. 

NOTE : Although only the 'call forwarding on no reply' case is depicted here , it serves as a basis for all other call 
forwarding modes description (Call Forwarding Unconditional, Call Deflection, Call Forwarding on 
Busy, Call Forwarding Not Logged-in ) for ACR generation : In all these cases, the AS AS implementing 
the CDIV service sends an Accounting-Request with Accounting-Record-Type indicating 
START_RECORD to record call forwarding execution (whatever the mode), when the final response is 
received from user-C. 

5.2.2.1.7.2 Communications Diversion (CDIV) - release 



The next figure shows the Diameter transactions occurring on release of the previous established communication, 
initiated by user C: 
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Home Network 





l.BYE 






















S-CSCF 


AS 




CDF 


1 












l.BYE (UserC) 












l.BYE 




2. Accounting Request [Stop] 








l.BYE 










200 OK 




















Close the AS CDR 






3. Accounting A 


nswer 








200 OK 




200 OK 
















200 OK 



































Figure 5.2.2.1.7.2-1 : Message Sequence Chart for Offline charging of CDIV service -release 

1) User C initiates release of the communication 

2) At session termination the AS implementing the CDIV service, sends an Accounting-Request with Accounting- 

Record-Type indicating STOP_RECORD to record stop the call for which User B has been forwarded. The AS 
CDR is closed. 



5.2.2.1 .8 Communication Waiting Charging (CW) 

The following figure shows the Diameter transactions that are required between Application Server, which implements 
the CW service and CDF for the callee (subscriber of CW). 
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S-CSCF 



1. INVITE- 



10. 180 Ringing 
Alert-lnfa _ 

urn: alert service 
call- waiting 



18. 20001^ 



AS 



P-CSCF 



2. INVITE 



2a. the AS determines 
the approaching NDUB? 
condition and inserts a 
CW indication in the 
INVITE request 



3. INVITE _ 
[ CW indication] 



4. INVITE _ 
[ CWindicatioji 



7. 180 Ringing- 



8 180 Ringing-^- 



8a . the AS inserts a Alertlnfo 
header with a CW urn into 
the 180 Ringing response 



9 . 180 Ringing 
Alert- Info: _ 

urn: alert service 
call- waiting 



9a. the AS has the possibili|y 
to generate a CW 
announcement 



12. 20001^ 



13. 20001^ 

14. 20001^ 



UE-B 



5. INVITE _ 
[ CW indicatioji 

-6. 180 Ringing- 



CDF 



6a . Possibility for User B tc 
react: release session 
HOLD,...] 
not part of CW 



11. 20001^ 



15. Accounting Request[Event] 



17. Accounting Answer 



16. Create an AS CDR 
indicating MWI in it 



Figure 5.2.2.1.8-1 : Message Sequence Chart for Offline charging of CW service 

1-2). The communication is initiated by UE-A by sending an INVITE request. The Request URI will include the URI of 
UE-B. After IFC evaluation in the S-CSCF the INVITE request is routed to the CW AS. 

2a). The AS detects the CW condition and inserts a CW indication into the INVITE request per procedures. 

3-4). The INVITE is routed to UE-B. 

5). UE-B recognizes the CW indication per procedures. 

6). UE-B sends back a 180 (Ringing) response. 
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[6a. out of scope: user B uses the HOLD service or releases a session in order to free resources] 

7-8). The 180 (Ringing) response is routed back to the AS. 

8a). The AS optionally inserts a Alert-Info with a 'CW urn into the 180 (Ringing) response. 

9-10). The 180 (Ringing) response is routed back to the communication origin. 

[9a. The AS may initiate an announcement to the calling user that the communication is a waiting communication, in 
accordance with 3GPP TS 24.628 [4].] 

1 1-14). UE-B sends back a 200 (OK) response to the CW AS and CW AS sends it to the S-CSCF. 

15-17). The CW AS sends Accounting Request[Event] to CDF, CDF creates an AS CDR and returns Accounting 
Answer to the CW AS. 

18). S-CSCF sends back a 200(OK) response to UE-A. 



5.2.2.1 .9 Explicit Communication Transfer (ECT) 

5.2.2.1 .9.1 Explicit Communication Transfer (ECT) : Blind Transfer 



The following figure shows the Diameter transactions that are required between Application Servers implementing the 
ECT service for the transferor and for the transferee, and CDF: a successful Blind Transfert from User A to User C, 
initiated by User B 

For diagram simplification, only one CDF is shown. 
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AS A 



S-CSCF B AS B 



CDF 



A and B established communication - B puts A on Hold 



1. REFER 



4. forward to AS 



1. REFER 



5.202 Accepted 

► 



1. REFER 



1. REFER 



1. REFER (ufier-C) 



2. forward to AS 



1. REFER (User C) 

► 



3. User-C =>ECT session-id 



1. REFER (ECT session id) 



More 202 Accepted signalling between (A,x-CSCF,AS-A ) and (x-CSCF,AS-B, B) 



6. BYE 



9.200 OK 



6. BYE 



6. BYE 



6. BYE 



,6. BYE 



6. BYE 



6. BYE 



7. Accounting Request 



[Stop] 



Close AS CDR 



8. Accounting Answer 



More 200 OK signalling between (A,x-CSCF,AS-A ) and (x-CSCF,AS-B, B) 



Media between User A and User B are terminated 



10. More signalling between (A,x-CSCF,AS-A ) and (x-CSCF,AS-B, B) are transferred 



Figure 5.2.2.1.9.1-1 : Message Sequence Chart for Offline charging of ECT service - Blind Transfer 

(parti) 
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Figure 5.2.2.1.9.1-2 : Message Sequence Chart for Offline charging of ECT service - Blind Transfert 

(part 2) 



In this scenario User A is the transferee, User B is the transferor, and User C is the transfer target. 

User A and User B are in an established communication for which, based on the Initial Filter Criteria (IPC) Rules 
indicating that User B is subscribed to the ECT supplementary service, the INVITE was forwarded to an AS 
implementing ECT (for User A and User B). 

User B puts User A on Hold 

1) User B sends REFER request in the existing A-B dialog, to initiate transfer User A to User C. 

2) this subsequent request is forwarded to the AS implementing ECT. 

3) AS generates an 'ECT Session Identifier' replacing User C as the new destination information, for remaining 
in the loop, for transferor"s role. 

4) On REFER receipt, this request is forwarded the AS implementing ECT. 

5) The REFER is accepted by User A, and 202 Accepted is transferred from User A to User B. 
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6-9) User B sends BYE for terminating original INVITE with User A, acknowledged by 200 OK from User A. 
AS B releases the media between User A and User B which are on hold, then sends an Accounting-Request with 
Accounting-Record-Type indicating STOP_RECORD to record termination of the dialogue between User A and 
UserB. 

10) More signalHng between (User A,x-CSCF,AS-A ) and (x-CSCF,AS-B,User B) : 

User A sends NOTIFY(100 Trying) associated to the received REFER, and User B acknowledges by 200 OK 

1 1) User A initiates a new session by sending an INVITE request with ' ECT Session Identifier' . 

12) AS implementing the ECT service correlates this INVITE to the initial session to be transferred and replaces 
'ECT Session Identifier' with User C for creating an INVITE towards UE-C. 

13) The destination User C party answers and a final response is received. 

14) Upon reception of the final response, the AS implementing the ECT service for the transferor, sends an 
Accounting-Request with Accounting-Record-Type indicating START_RECORD/EVENT_RECORD to 
record Transfer execution. 

15) The CDF acknowledges the reception of the data and opens/creates an AS CDR. 

16) Upon reception of the final response, the AS implementing the ECT service for the transferee, sends an 
Accounting-Request with Accounting-Record-Type indicating START_RECORD/EVENT_RECORD to record 
User A is transferred, with specific indicator on the transferee" s 'subscriber role' (whether the transferee was 
engaged in an originating call or in a terminating call) before the transfer execution. 

17) The CDF acknowledges the reception of the data and opens/creates an AS CDR. 

NOTE : The "Consultative Transfer" scenario mainly differs from the "Blind transfer" on the transfer establishment 
phase : when User B has put User A on Hold, User B establishes a communication towards User C and 
puts User C on Hold, then User B initiates the REFER for the transfer triggering. The Accounting- 
Record-Type indicating START_RECORD for recording Transfer execution occurs at the same steps for 
both scenario: on the final response associated to INVITE towards User C for the transferor and for the 
transferee. 



5.2.2.1 .9.2 Explicit Communication Transfer (ECT)) : Release 

The following figure shows the Diameter transactions that are required between Application Servers implementing the 
ECT service for the transferor and for the transferee, and CDF: release from User A, after a successful Blind Transfer 
from User A to User C, initiated by User B. 
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S-CSCF A 



AS A 



S-CSCF B AS B 



CDF 



l.BYE 



l.BYE 



l.BYE 



l.BYE 



2. Accounting Request [Stop] 



3. Accounting Answer 



l.BYE 



l.BYE 



Close AS CDR 



4. Accounting Request 
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Close AS CDR 



5. Accounting Answer 



l.BYE(User-C) 



Figure 5.2.2.1.9.2-1 : Message Sequence Chart for Offline charging of ECT service - Release 



1) User A initiates release of the communication 

2-3) At session termination the AS implementing the ECT service for the transferee, sends an Accounting-Request 
with Accounting-Record-Type indicating STOP_RECORD to record stop the call for which User A has been 
transferred. 

4-5) At session termination the AS implementing the ECT service for the transferor, sends an Accounting-Request 
with Accounting-Record-Type indicating STOP_RECORD to record stop the call transferred by User B. The 
AS CDR is closed. 



5.2.2.1.10 



Message Waiting Indication Charging (MWI) 



The following figure shows the Diameter transactions that are required between Application Server (MWI), which 
implements the IVIWI service and CDF. 
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UE 
(Subscriber) 

1. SUBSCRIBE 



Visited Network 



S-CSCF 



2. Evaluation of 

initial filter 

criteria 



6. 200 (OK) 

8. NOTIFY 
9. 200 (OK) 



Subscriber's Home Network 



3. SUBSCRIBE 



5. 200 (OK) 



7. NOTIFY 



10. 200 (OK) 



AS(IVIWI) 



CDF 



4. Subscriber 
Authorisation 



1 1 . Accounting 
Request[Event] 



1 3. Accounting 
Answer 



12. Create an AS CDR 

indicating MWI 

In it 



Figure 5.2.2.1.10-1 : Message Sequence Chart for Offline charging of MWI service 

1-6) UE subscribes to AS (MWI) and the AS (MWI) returns 200 OK. 

7-10) The AS (MWI) sends NOTIFY request to S-CSCF and the subscriber UE acknowledges the NOTIFY request. 

11-13) The AS (MWI) sends Accounting Request [Event] message to CDF, CDF creates an AS CDR and returns 
Accounting Answer to the AS (MWI). 



5.2.2.1.11 



CONF Charging 



During a conference, user could create the conference, join the conference, invite another user to the conference and 
leave the conference, according to 3GPP TS24.605. The following subclauses respectively show the Diameter 
transactions that are required between Application Server, which implements the CONF service and CDF corresponding 
different conference scenarios. 
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5.2.2.1.11.1 



CONF Charging - user creating a conference 



UE#1 



7. 183 Session_ 
Progress 

8 . PRACK — 



-15. 200ok 



< 20 . 200ok 

21 . AC&- 



S-CSCF 



- 1 . INVITE H 

2 . 100 Trying 



11 . 200ok 

12 . UPDATE H 



- 3 . INVITE 
4 . 100 Trying— 



6. 183 Session 
Progress 



16 . 200ok 



■22.ACI^ 



AS 



CDF 



5 . Allocate 
Conference URI 



■ 9 . PRACK ► 

10 . 200ok 



13 . UPDATE H 

< 14 . 200ok 



17. ACR[Start/Event]- 



18. Open/Create an AS 
CDR for the conference 



-19. ACA 



Indicate CONF on 
the AS CDR 



Figure 5.2.2.1.11.1-1 : Message Sequence Chart for Offline charging of CONF service- User creating a 

conference 



1-2). The communication is initiated by UE#1 by sending an INVITE request to S-CSCF. And S-CSCF sends back 100 
Trying reponse to inform UE#1 to wait for a while because the request is being treated. 

3-4). S-CSCF transfers INVITE request from UE#1 to CONF AS and the CONF AS sends back 100 Trying response to 
inform S-CSCF to wait for a while because the request is being treated. 

5). The CONF AS allocates the conference URI. 

6-16). After the media resource negociation process, the CONF AS sends back 200 ok response. 

17-19). The CONF AS sends Accounting Request[Start]/Accounting Request[Event] to CDF, then the CDF 
opens/creates an AS CDR for the conference with CONF indication on the AS CDR and renturns Accounting Answer 
to the CONF AS. 
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5.2.2.1.11.2 



CONF Charging - user joining a conference 



The following figure shows the Diameter transactions that are required between Application Server, which implements 
the CONF service and CDF corresponding to the conference scenario; user joining a conference. 



UE#1 



S-CSCF 



AS 



CDF 



- 1 . INVITE 
2 . lOOTrying — 



6. 183 session 



10 . 200ok 



11 . UPDATE 



14. 200ok 



The conference has already been created 



progress 
7 . PRACK ► 



< 19 . 200ok 

20 . ACK H 



- 3 . INVITE 
4 . lOOTrying- 



5. 183 session 
progress 



PRAC&- 



9 .200ok 



15 . 200ok 



■ 21 . AC&- 



12 . UPDATE H 

- 13 . 200ok 



16. ACR[Interim/Event]- 



17. Update/Create an 

AS CDR for the 

conference 



ACA 



Indicate CONF in 
the AS CDR 



Figure: 5.2.2.1 .1 1 .2-1 CONF Charging - user joining a conference 

1-2). The conference has already been created. UE#1 sends an INVITE request to S-CSCF in order to join in the 
conference. And S-CSCF sends back SIP 100 Trying reponse to inform UE#1 to wait for a while because the request is 
being treated. 

3-4). S-CSCF transfers INVITE request from UE#1 to CONF AS and the CONF AS sends back SIP 100 Trying 
response to inform S-CSCF to wait for a while because the request is being treated. 

5-15). After the media resource negociation process, the CONF AS sends back SIP 200 ok response. 
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16-18). The CONF AS sends Accounting Request[Interim/Event] to CDF, CDF updates or creates an AS CDR for the 
conference and renturns Accounting Answer to the CONF AS. 



5.2.2.1.11.3 



CONF Charging - user inviting anotiner user to a conference 



The following figure shows the Diameter transactions that are required between Application Server, which implements 
the CONF service and CDF corresponding to the conference scenario: user being invited into a conference. 



UE#1 



S-CSCF 



AS 



CDF 



UE#2 



The conference has ateady been created. 



■< 6 . NOTIFY 

7. 2000k ► 



■ 1 . REFER 



4. 202 Accepted ■ 



< 3. 202 Accepted - 

K 5 .NOTIFY 



-2. REFER 



200ok 



9. INVITE 
- 10.2000k 



■II. ACR[Interim/Event-]- 



12. Update/Create an 
AS CDR for the conference 



■ 13. AC A 



Indicate CONF in 
the AS CDR 



Figure: 5.2.2.1 .1 1 .3-1 CONF Charging - user inviting another user to a conference 

1-2). The conference has already been created. UE#1 sends a REFER request to S-CSCF in order to invite UE#2 into 
the conference. 

3-4). The CONF AS sends back 202 Accepted response to UE#1 via some related NEs like S-CSCF to indicate that he 
has received the REFER request successfully. 

5-6). The CONF AS sends a NOTIFY request corresponding the REFER request to UE#1. 

7-8). UE#1 sends back SIP 200 ok reponse to the CONF AS. 

9-10). The CONF AS sends an INVITE request to UE#2 in order to invite him into the conference. And UE#2 sends 
back SIP 200 ok response to the CONF AS. 

11-13) The CONF AS sends Accounting Request [Interim/Event] to CDF, CDF updates or creates an AS CDR for the 
conference and renturns Accounting Answer to the CONF AS. 



5.2.2.1.11.4 



CONF Charging - user ieaving a conference 



The following figure shows the Diameter transactions that are required between Application Server, which implements 
the CONF service and CDF corresponding to the conference scenario: user leaving a conference. 
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UE#1 



S-CSCF 



AS 



CDF 



The conference has already been created. 



-1. BYE 



■7.200ok 



lO.NOTIFY ■ 



1 1 . 200ok- 



-2. BYE 



— 3. ACR[Stop/Interim/Event] ■ 



6. 200 ok- 



8. NOTIFY 



4. CloseAJpdate/Create 

an AS CDR for the 

conference 



5. ACA 



^ 



9. NOTIFY to other 
conference participants 



-12.200ok- 



Indicate CONF in 
the AS CDR 



Figure: 5.2.2.1.11.4-1 CONF Charging - user leaving a conference 

1-2). The conference has already been created. UE#1 sends a BYE request to the CONF AS in order to quit the 
conference. 

3-5). The CONF AS sends Accounting Request[Interim/Event] to CDF, CDF updates or creates an AS CDR for the 
conference and renturns Accounting Answer to the CONF AS. Conference termination should refer to the description of 
subclause 5.3.2.7 in TS 24.147, e.g. If there isn"t any conference policy and the last online conference user quits the 
conference could be considered as the conference termination, when the last online conference user quits the conference 
(sends a BYE request to the CONF AS), the CONF AS sends Accounting Request [Stop/Event] to CDF, CDF stops or 
creates an AS CDR for the conference and returns Accounting Answer to the CONF AS. 

6-7). The CONF AS sends back SIP 200 ok response to UE#1. 

8-10). The CONF AS sends a NOTIFY request to other conference participants that UE#1 has quitted the conference. 

11-12). Other conference participants sends back SIP 200 ok response to the CONF AS. 



5.2.2.2 



Message Flows - Error Cases and Scenarios 



Error cases and Scenarios for SIP related procedures and Diameter related procedures used for MMTel Service and 
Supplementary Services Charging are defined in TS 32.260 [20]. 

5.2.3 GTP" record transfer flows 

As in IMS offline charging, GTP" is not used between CDF and CGF for MMTel offline charging, because CDF and 
CGF are combined into CCF. 

5.2.4 Bi CDR file transfer 



For further details on the Bj protocol application refer to 3GPP TS 32.297 [52]. 
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5.3 MMTel online charging scenarios 

Editor" s Note : MMTel online charging is ffs 

5.3.1 Basic principles 

Online charging of MMTel services is done according to the general principles of Diameter Credit-Control Applications 
(DCCA) as specified in TS 32.299 [50]. 

Editor"s note: The generated online charging messages contain distinguishable service usage data for any of the sub- 
services. 

5.3.2 Diameter message flows 

Following message flows are defined in TS 32.260 [20], and can be re-used for charging the basic multimedia 
telephony capabilities: 

• Successful Session Establishment 

• Successful Session Establishment with Early Media Negotiation 

• Mid-Session Procedures 

• Session Release 
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6 Definition of charging information 

6.1 Data description for MMTel offline charging 
6.1 .1 Rf Diameter message contents 

For offline charging, the different service CTFs supporting MMtel specific service charging generate accounting 
information transferred to the CDF using the Diameter accounting appHcation, as described in the TS 32.299 [50]. 

The Charging Data Request and Charging Data Response are used for this MMTel service offline charging, as 
described in TS 32.260 [20]. 

6.1 .1 .1 Charging Data-Request Message Description 

The generic Charging Data-Request message described in TS 32.260[20] used for MMTel offline charging is enhanced 
with specific MMTel service information. 

The following table illustrates the overall Charging Data-Request message as used for MMTel offline charging. 
Table 6.1.1.1 : Charging Data Request Message Contents 



Field [Category | ^»^ Description 



See Charging Data-Request message fields described in TS 32.260 [20] 



Service Information Om This field holds tlie MMTel specific parameter and is described in clause 6.3. 



NOTE: Detailed descriptions of the fields are provided in 3GPP TS 32.299 [50] . 

6.1 .1 .2 Charging Data Response Message Description 

The generic Charging Data-Responset message described in TS 32.260[20] is used for MMTel offline charging. 

6.1 .2 GTP" message contents 

Not applicable. Refer to subclause 5.2.3 for further information. 

6.1 .3 CDR Description on the Bi Interface 
6.1.3.1 CDR Field Type 

The MMTel CDR content and format description is based on TS 32.260[20] AS-CDR description, enhanced with 
specific MMTel service information. 

The content of MMTel CDR type is defined in the table in clause 6.1.3.3. The field definition includes the field name, 
category and description. The detailed field descriptions are provided in TS 32.298 [51]. 

The CDF provides the CDRs at the Bi interface in the format and encoding described in TS 32.298 [51]. Additional 
CDR formats and contents may be available at the interface to the billing system to meet the requirements of the billing 
system, these are outside of the scope of 3GPP standardisation. 
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6.1.3.2 CDR Triggers 

Accounting information for MMTel services charging is transferred from the CTFs supporting MMtel service charging 
to the CDF, using Charging Data Request Start, Interim Stop or Event messages, depending on MMTel service 
behaviour (detailed in clause 5.2.2). Within the CDF, the CDRs triggering follows the same principle as described for 
SIP sessions in TS 32.260[20] : MMTel CDR is opened upon reception of a Charging Data Request [Start] message, 
closed upon reception of a Charging Data Request [Stop] message, updated upon reception of a Charging Data Request 
[Interim], and created upon reception of a Charging Data Request [Event]. 

6.1.3.3 MMTel- AS CDR Content 

The MMTel CDR content and format description is based on TS 32.260[20] AS-CDR description, enhanced with 
specific MMTel service informations. 

The following table illustrating the overall MMTel CDR content, is extracted from TS 32.260[20] AS-CDR Charging 
data table, and adaptated for MMTel service, with specific descriptions and new MMtel information field. 

The detailed description of the field is provided in TS 32.298 [51]. 
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Table 6.1.3.3: Charging Data of MMTel CDR 



Field 


Category 


Description 


Record Type 


M 


Identifies the MMTel service record. 


Retransmission 


Oc 


Used as defined in 3GPP TS 32.260 [20]. 


SIP Metiiod 


Oc 


Used as defined in 3GPP TS 32.260 [20]. 


Event 


Oc 


Used as defined in 3GPP TS 32.260 [20]. 


Expires Information 


Oc 


Used as defined in 3GPP TS 32.260 [20]. 


Role of Node 


Om 


This fields indicates the role of the AS implementing MMTel service 
and supplementary services 


Node Address 


Om 


Used as defined in 3GPP TS 32.260 [20]. 


Session ID 


Om 


Used as defined in 3GPP TS 32.260 [20]. 


List Of Calling Party Address 


Om 


Used as defined in 3GPP TS 32.260 [20]. 


Called Party Address 


Om 


Used as defined in 3GPP TS 32.260 [20]. 


Number Portability routing information 


Oc 


Used as defined in 3GPP TS 32.260 [20]. 


Carrier Select routing information 


Oc 


Used as defined in 3GPP TS 32.260 [20]. 


Requested Party Address 


Oc 


Used as defined in 3GPP TS 32.260 [20]. 


List of Subscription Id 


Om 


Used as defined in 3GPP TS 32.260 [20]. 


List of Called Asserted Identity 


Oc 


Used as defined in 3GPP TS 32.260 [20]. 


Service Request Time Stamp 


Om 


Used as defined in 3GPP TS 32.260 [20]. 


Service Delivery Start Time Stamp 


Om 


Used as defined in 3GPP TS 32.260 [20]. 


Service Delivery End Time Stamp 


Oc 


Used as defined in 3GPP TS 32.260 [20]. 


Record Opening Time 


Oc 


Used as defined in 3GPP TS 32.260 [20]. 


Record Closure Time 


Om 


Used as defined in 3GPP TS 32.260 [20]. 


Inter Operator Identifiers 


Oc 


Used as defined in 3GPP TS 32.260 [20]. 


Local Record Sequence Number 


Om 


Used as defined in 3GPP TS 32.260 [20]. 


Record Sequence Number 


Oc 


Used as defined in 3GPP TS 32.260 [20]. 


Cause For Record Closing 


Om 


Used as defined in 3GPP TS 32.260 [20]. 


Incomplete CDR Indication 


Oc 


Used as defined in 3GPP TS 32.260 [20]. 


IMS Charging Identifier 


Om 


Used as defined in 3GPP TS 32.260 [20]. 


List of SDP Media Components 


Oc 


Used as defined in 3GPP TS 32.260 [20]. 


GGSN Address 


Oc 


Used as defined in 3GPP TS 32.260 [20]. 


Service Reason Return Code 


Om 


Used as defined in 3GPP TS 32.260 [20]. 


List of Message Bodies 


Oc 


Used as defined in 3GPP TS 32.260 [20]. 


Access Networl< Information 


Oc 


Used as defined in 3GPP TS 32.260 [20]. 


Service Context Id 


Om 


Used as defined in 3GPP TS 32.260 [20]. 


IMS Communication Service ID 


Oc 


Used as defined in 3GPP TS 32.260 [20]. 


MMTel information 


Oc 


This field includes a list of MMTel supplementary services which may 
occur within the same AS. 

The MMTel supplementary services related informations are 
described in Clause 6.3.1.2. 


Record Extensions 


Oc 


Used as defined in 3GPP TS 32.260 [20]. 



6.2 Data description for IVIIVITel online charging 

Editor" s Note : MMTel online charging is ffs. 

6.2.1 Diameter message contents 

6.3 IVIIVITel Charging Specific Parameters 
6.3.1 Definition of MMTel charging information 

The MMTel Information parameter used for MMTel charging is provided in the Service Information parameter. 
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6.3.1 .1 MMTel charging information assignment for Service Information 

The components in the Service Information that are use for MMTel charging can be found in Table 6.3.1.1. 
Table 6.3.1.1: Service Information used for MMTel Charging 



Field 


Category 


Description 


Service Information 


Om 


A set of fields hold the 3GPP specific parameter as 
defined in 3GPP TS 32.299 [50]. 


Subscription Id 


Om 


Used as defined in 3GPP TS 32.260 [20]. 


IMS Information 


Oc 


A set of fields hold the IMS specific parameters. The 
details are defined in 3GPP TS 32.260 [20]. 


Event Type 


Oc 


Used as defined in 3GPP TS 32.260 [20]. 


Role of Node 


Oc 


Used as defined in 3GPP TS 32.260 [20]. 


Node Functionality 


Om 


Used as defined in 3GPP TS 32.260 [20]. 


User Session ID 


Oc 


Used as defined in 3GPP TS 32.260 [20]. 


Calling Party Address 


Oc 


Used as defined in 3GPP TS 32.260 [20]. 


Called Party Address 


Oc 


Used as defined in 3GPP TS 32.260 [20]. 


Number Portability routing 
information 


Oc 


Used as defined in 3GPP TS 32.260 [20]. 


Carrier Select routing information 


Oc 


Used as defined in 3GPP TS 32.260 [20]. 








Requested Party Address 


Oc 


Used as defined in 3GPP TS 32.260 [20]. 


Called Asserted Identity 


Oc 


Used as defined in 3GPP TS 32.260 [20]. 


Time stamp 


Oc 


Used as defined in 3GPP TS 32.260 [20]. 


Inter Operator Identifier 


Oc 


Used as defined in 3GPP TS 32.260 [20]. 


IMS Charging Identifier 


Oc 


Used as defined in 3GPP TS 32.260 [20]. 


Early Media Description 


On 


Used as defined in 3GPP TS 32.260 [20]. 


SDP Session Description 


Oc 


Used as defined in 3GPP TS 32.260 [20]. 


SDP Media Components 


Oc 


Used as defined in 3GPP TS 32.260 [20]. 


Message Bodies 


Oc 


Used as defined in 3GPP TS 32.260 [20]. 


Access Network Information 


Oc 


Used as defined in 3GPP TS 32.260 [20]. 


IMS Communication Service Id 


Oc 


Used as defined in 3GPP TS 32.260 [20]. 


Cause Code 


Oc 


Used as defined in 3GPP TS 32.260 [20]. 


MMTel Information 


Om 


This field holds a set of MMTel services with theirs 
specific parameters. The details are defined in 
clause 6.3.1.2. 



Editor" s Note : content described in this table is to be further finalized 



6.3.1.2 



Definition of the MMTel Information 



MMTel specific charging information is provided within the MMTel Information, and the detailed structure of the 
MMTel Information can be found in table 6.3.1.2. 
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Table 6.3.1 .2: Structure of the MMTel Information 



Field 


Category Description | 


Supplementary Service 


Om 


This is a grouped field comprising several sub-fields associated with one 
supplementary service. It can be present multiple times as necessary to 
present the parallel activity of the different supplementary services. 


Service Type 


Om 


This field holds the type of the Supplementary Service, i.e. OIP, OIR, TIP, 
TIR, CW, HOLD, CB, MWI, CONF, CDIV, ECT. 


Service IVIode 


Oc 


This field holds the mode of specific Service Type, i.e. for CB: ACR, ICB, 
OCB and for CDIV: CPU, CFB, CFNR, CFNRc, CFNL, CFUDB. 








Number of 
diversions 


Oc 


This field holds the number of diversions for CDIV. 


Associated party 
address 


Oc 


This field holds additional party identification needed for the service 
charging, i.e. for CDIV the 'forwarding party', for ECT the 'transferor'. 








Service id 


Oc 


This field holds the conference ID for CONF supplementary service 


Change Time 


Oc 


This field holds the time of the requested action indicated in the 'Participant 
Action Type' during the CONF supplementary service. It provides the time 
stamps for the CONF supplementary service parameters reporting. 
When the action is set to 'CREATE', this field indicates the start time of the 
CONF supplementary service. 

When the action is set to 'OUIT' and Number Of Participants holds the value 
'0', this field indicates the end time of the CONF supplementary service. 


Number Of 
Participants 


Oc 


This field holds the number of parties who are currently attached to the 
Conference at the time stamped indicated in the 'Change Time', for the 
CONF supplementary service. 


Participant Action 
Type 


Oc 


This field holds the participant action type for CONF supplementary service 
(CREATE_CONF, JOIN_CONF, INVITE_CONF, QUIT_CONF) at the time 
stamped indicated in the 'Change Time'. 


Subscriber role 


Om 


This field indicates subscriber role (originating party or terminating party) for 
UE when AS acts as B2BUA role and used for AS only 



Editor" s Note : content and structure (Service Type and Service Mode) described in this table is to be further 
finalized 



6.3.1 .3 Support of MMTel Information in MMTel Offline Charging 

In table 6.3.1.3, the supported Operation Types for Service Type field within the MMTel Information on the Rf 
interface are presented. The other MMTel Information fields are not detailed. 

The supported Operation Types for Service Information fields, used in the Charging Data Request and Response 
messages for MMTel charging, other than MMTel Information fields, are described in TS 32.260 [20]. 

Operation Types for Service Type, encompasse the various situations, where the basic MMTel service Charging Data 
Request messages are sent from: 

a separate entity (another AS or S-CSCF), than the AS implementing the supplementary service, 

the same AS. 

Each service may be reported through a dedicated Charging Data Request Message or combined Charging Data Request 
Messages (regrouped supplementary services or with basic MMTel service). 

Table 6.3.1.3: Supported values for Service Type in MMTel Information. 



ETSI 



3GPP TS 32.275 version 8.2.0 Release 8 



44 



ETSI TS 132 275 V8.2.0 (2009-10) 



Field 


Node Type 


AS 


Supported Operation Types 


S/l/S/E 






Service Type 




01 P (see note 1) 


SISE 


OIR 


SISE 


TIR 


SISE 


TIR (see note 2) 


SISE 


CW 


SISE 


HOLD (see note 3) 


SISE 


CB (see note 2) 


SISE 


MWI 


— E 


CONF 


SISE 


CDIV 


SISE 


CDIVN 


SISE 


ECT 


SISE 


NOTE 1 : Only present at terminating side. 

NOTE 2: Terminating side service. 

NOTE 3: AS may be involved for announcement purposes. 



6.3.1.4 



Support of MMTel Information in MMTel Online Charging 



In table 6.3.1.4 the basic structure of the supported fields within the MMTel Information in the Debit and Reserve Units 
Request for IMS online charging on the Ro interface are presented. The Operation types are listed in the following 
order: I (initial)/!! (update )/T (terminate)/E (event). Therefore, when all Operation types are possible it is marked as 
lUTE. If only some Operation types are allowed for a node, only the appropriate letters are used (i.e. lUT or E) as 
indicated in the table heading. The omission of an Operation type for a particular field is marked with "-" (i.e. lU-E). 
Also, when an entire filed is not allowed in a node the entire cell is marked as "-". 

Table 6.3.1.4: Supported values in Debit and Reserve Units Request Message MMTel Information 



Field 


Node Type 


AS 


Supported Operation Types 


l/U/T/E 






Service Type 




OIP (see note 1) 


- 


OIR (see note 1) 


- 


TIP (see note 1) 


- 


TIR (see note 1) 


- 


CW (see note 1 ) 


- 


HOLD (see note 1) 


- 


CB (see note 1) 


- 


MWI (see note 1) 


- 


CONF 


lUTE 


CDIV 


I--T- 


CDIVN 


— E 


ECT 


I--T- 


NOTE 1 : Only reported in offline charging. 



Editor"s note: The correct use indication at AS is ffs. 
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Annex A (informative): 
Bibliography 

a) The 3GPP charging specifications 



3GPP TS 32.250: "Telecommunication management; Charging management; Circuit Switched 
(CS) domain charging". 

3GPP TS 32.251: "Telecommunication management; Charging management; Packet Switched 
(PS) domain charging". 

3GPP TS 32.252: "Telecommunication management; Charging management; Wireless Local Area 
Network (WLAN) charging". 

3GPP TS 32.271: "Telecommunication management; Charging management; Location Services 
(LCS) charging". 

3GPP TS 32.272: "Telecommunication management; Charging management; Push-to-talk over 
Cellular (PoC) charging". 

3GPP TS 32.273: "Telecommunication management; Charging management; Multimedia 
Broadcast and Multicast Service (MBMS) charging". 

3GPP TS 32.274: "Telecommunication management; Charging management; Short Message 
Service (SMS) charging". 

b) Common 3GPP specifications 

3GPP TS 23.002: "Network architecture". 

c) other Domain and Service specific 3GPP / ETSI specifications 

3GPP TS 22.002: "Circuit Bearer Services (BS) supported by a Public Land Mobile Network 

3GPP TS 22.003: "Circuit Teleservices Supported by a Public Land Mobile Network (PLMN)". 

3GPP TS 22.004: "General on Supplementary Services". 

3GPP TS 23.009: "Handover procedures" 

3GPP TS 23.040: "Technical reahzation of the Short Message Service (SMS)". 

3GPP TS 23.140: "Multimedia Messaging Service (MMS); Functional description; Stage 2". 

3GPP TS 23.271: "Location Services (LCS); Functional description; Stage 2". 

d) Relevant ITU Recommendations 

ITU-T Recommendation E. 164: "The international public telecommunication numbering plan". 

ITU-T Recommendation Q.767: "Application of the ISDN user part of CCITT signalling System 
No. 7 for international ISDN interconnections". 

ITU-T Recommendation X.25: "Interface between Data Terminal Equipment (DTE) and Data 
Circuit-terminating Equipment (DCE) for terminals operating in the packet mode and connected to 
public data networks by dedicated circuit". 

ITU-T Recommendation X. 121: "International numbering plan for public data networks". 

e) Relevant IETF RFCs 

IETF RFC 959 (1985): "File Transfer Protocol". 
IETF RFC1350: "The TFTP Protocol (Revision 2)". 
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